A common requirement for a computer system user interface (UI) is the capability to display some information to the user when a user input device controlled pointer (e.g. mouse pointer) passes over some part of the interface, approaches part of the interface, or lingers over part of the interface. Such information can offer additional explanation of that part of the interface, and of the consequences of the user interacting with it, and can be particularly useful when the interface itself omits some of that information in order to reduce the screen area it uses.
For example, many UIs incorporate push buttons which display small icon graphics representing the task they perform. Such buttons can be gathered into rows or columns, sometimes called "tool bars", and the area of screen which they occupy is very much less than would be required if each push button carried a full textual description of its function. However, the small icon graphic may not always be clearly understood, especially by a new user of the interface, so a textual explanation for each button, shown if the mouse lingers over that button, can greatly enhance the ease of use of the interface.
The information can be presented in many different ways. Some examples include pop-up boxes or bubbles containing text, via which text overlays the existing interface with suitable graphics to delineate it from its surroundings and perhaps to reinforce which part of the interface it relates to. Alternatively, the text can be shown on a status bar, or in a message window, or it could be spoken via a suitable audio interface. Sometimes, the information may not take the form of simple text presentation, but some other alteration applied to the interface, such as changing an outline colour, animating a graphic, initiating a sound effect, and there are of course many other possibilities.
In an interface even of only moderate complexity, there may be many different parts to which such information can be applied, and managing this collection of pieces of information can present a significant challenge even to one skilled in the art. This problem increases for interfaces which change dynamically, especially if parts of the interface are to be added and managed by program code over which an interface designer has no direct control. For example, it is known in the art for certain applications to operate as containers into which a variety of components (applets or UI controls) can be inserted, with different components possibly being created at different times by different people. Additions to the interface due to the insertion of such components by a system end user or interface designer are not readily under the specific control of the developer of the container.
In a platform-independent component programming environment, such as Java (trademark of Sun Microsystems Inc.), no help information is generally presented for application components unless the individual components themselves include methods for this presentation, since there is currently no applicable generic mechanism for presenting help information. This is a distinction from less dynamic environments where applications written for a particular operating system are often coded to make calls to standard operating system functions to present `help` information. Such standard operating system functions do not typically provide mechanisms for handling help presentation for dynamically changing interfaces.
Although it avoids reliance on specific operating system functions, requiring components to be fully responsible for presenting their help information significantly increases the effort of component development. In particular, defining a state model for a sensitive screen area (to determine what pointer movements should trigger presentation of help information, when the help information should be removed, etc) is a complex and time-consuming task.
Also, from the end user's perspective, if each component is responsible for presentation of help information then interfaces will often have inconsistent information presentation for similar interactions with different components (for example, different styles of help bubble may appear). This may be very confusing for the user. Furthermore, the information presentation functions which are provided by an operating system or built into a component may not provide the type of information presentation effects that the user really wants (for example, if the user wants audio help information but only text-based "hover help" is supported).
A further difficulty arises due to the demands users make upon the display of information as described above. In order that the information is presented in a timely fashion to those users who require it, but does not impede the activities of those users who do not require it, a more sophisticated behaviour must be provided than a simple implementation might achieve. This is especially true because a user who does not require assistance at one time may require that same assistance at another time, or when using an unfamiliar part of the interface at the same time. If the behaviour the user requires and expects is not provided, the user may become irritated and frustrated, and the ease of use of the interface may be reduced rather than increased.